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Abstract 


Floor control is a means to manage joint or exclusive access to 
shared resources in a (multiparty) conferencing environment. 
Thereby, floor control complements other functions -- such as 
conference and media session setup, conference policy manipulation, 
and media control -- that are realized by other protocols. 


This document specifies the Binary Floor Control Protocol (BFCP). 
BFCP is used between floor participants and floor control servers, 
and between floor chairs (i.e., moderators) and floor control 
servers. 
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Introduction 


Within a conference, some applications need to manage the access to a 
set of shared resources, such as the right to send media to a 
particular media session. Floor control enables such applications to 
provide users with coordinated (shared or exclusive) access to these 
resources. 


The Requirements for Floor Control Protocol [9] list a set of 
requirements that need to be met by floor control protocols. The 
Binary Floor Control Protocol (BFCP), which is specified in this 
document, meets these requirements. 


In addition, BFCP has been designed so that it can be used in 
low-bandwidth environments. The binary encoding used by BFCP 
achieves a small message size (when message signatures are not used) 
that keeps the time it takes to transmit delay-sensitive BFCP 
messages to a minimum. Delay-sensitive BFCP messages include 
FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It 
is expected that future extensions to these messages will not 
increase the size of these messages in a significant way. 


The remainder of this document is organized as follows: Section 2 
defines the terminology used throughout this document, Section 3 
discusses the scope of BFCP (i.e., which tasks fall within the scope 
of BFCP and which ones are performed using different mechanisms), 
Section 4 provides a non-normative overview of BFCP operation, and 
subsequent sections provide the normative specification of BFCP. 


Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 
described in BCP 14, RFC 2119 [1] and indicate requirement levels for 
compliant implementations. 


Media Participant: An entity that has access to the media resources 
of a conference (e.g., it can receive a media stream). In floor- 
controlled conferences, a given media participant is typically 
colocated with a floor participant, but it does not need to be. 
Third-party floor requests consist of having a floor participant 
request a floor for a media participant when they are not colocated. 
The protocol between a floor participant and a media participant 
(that are not colocated) is outside the scope of this document. 


Client: A floor participant or a floor chair that communicates with a 
floor control server using BFCP. 
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Floor: A temporary permission to access or manipulate a specific 
shared resource or set of resources. 


Floor Chair: A logical entity that manages one floor (grants, denies, 
or revokes a floor). An entity that assumes the logical role of a 
floor chair for a given transaction may assume a different role 
(e.g., floor participant) for a different transaction. The roles of 
floor chair and floor participant are defined on a transaction-by- 
transaction basis. BFCP transactions are defined in Section 8. 


Floor Control: A mechanism that enables applications or users to gain 
safe and mutually exclusive or non-exclusive input access to the 
shared object or resource. 


Floor Control Server: A logical entity that maintains the state of 
the floor(s), including which floors exists, who the floor chairs 
are, who holds a floor, etc. Requests to manipulate a floor are 
directed at the floor control server. The floor control server of a 
conference may perform other logical roles (e.g., floor participant) 
in another conference. 


Floor Participant: A logical entity that requests floors, and 
possibly information about them, from a floor control server. An 
entity that assumes the logical role of a floor participant for a 
given transaction may assume a different role (e.g., a floor chair) 
for a different transaction. The roles of floor participant and 
floor chair are defined on a transaction-by-transaction basis. BFCP 
transactions are defined in Section 8. In floor-controlled 
conferences, a given floor participant is typically colocated with a 
media participant, but it does not need to be. Third-party floor 
requests consist of having a floor participant request a floor for a 
media participant when they are not colocated. 


Participant: An entity that acts as a floor participant, as a media 
participant, or as both. 


3. Scope 


As stated earlier, BFCP is a protocol to coordinate access to shared 
resources in a conference following the requirements defined in [9]. 
Floor control complements other functions defined in the XCON 
conferencing framework [10]. The floor control protocol BFCP defined 
in this document only specifies a means to arbitrate access to 
floors. The rules and constraints for floor arbitration and the 
results of floor assignments are outside the scope of this document 
and are defined by other protocols [10]. 
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Figure 1 shows the tasks that BFCP can perform. 


+--------- + 
| Floor | 
| Chair | 
| | 
+--------- + 
a 
Notification | Decision 
| | 
TERE 
Floor | v 
tS SSS SSS + Request +--------- + ee ea aa re + 
Floor | ----------- >| Floor | Notification | Floor 
Participant Control |------------- >| Participant 
K ice Server 
A aege See aaa + Granted or +--------- + hae SSeS SSeS Ses + 
Denied 


Figure 1: Functionality provided by BFCP 
BFCP provides a means: 


o for floor participants to send floor requests to floor control 
servers. 


o for floor control servers to grant or deny requests to access a 
given resource from floor participants. 


o for floor chairs to send floor control servers decisions regarding 
floor requests. 


o for floor control servers to keep floor participants and floor 
chairs informed about the status of a given floor or a given floor 
request. 


Even though tasks that do not belong to the previous list are outside 
the scope of BFCP, some of these out-of-scope tasks relate to floor 
control and are essential for creating floors and establishing BFCP 


connections between different entities. In the following 
subsections, we discuss some of these tasks and mechanisms to perform 
them. 
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3.1. Floor Creation 


The association of a given floor with a resource or a set of 
resources (e.g., media streams) is out of the scope of BFCP as 
described in [10]. Floor creation and termination are also outside 
the scope of BFCP; these aspects are handled using the conference 
control protocol for manipulating the conference object. 
Consequently, the floor control server needs to stay up to date on 
changes to the conference object (e.g., when a new floor is created). 


3.2. Obtaining Information to Contact a Floor Control Server 
A client needs a set of data in order to establish a BFCP connection 


to a floor control server. These data include the transport address 
of the server, the conference identifier, and a user identifier. 


Clients can obtain this information in different ways. One is to use 
an SDP offer/answer [8] exchange, which is described in [7]. Other 
mechanisms are described in the XCON framework [10] (and other 


related documents). 
3.3. Obtaining Floor-Resource Associations 


Floors are associated with resources. For example, a floor that 
controls who talks at a given time has a particular audio session as 
its associated resource. Associations between floors and resources 
are part of the conference object. 


Floor participants and floor chairs need to know which resources are 
associated with which floors. They can obtain this information by 
using different mechanisms, such as an SDP offer/answer [8] exchange. 
How to use an SDP offer/answer exchange to obtain these associations 
is described in [7]. 


Note that floor participants perform SDP offer/answer exchanges 
with the conference focus of the conference. So, the conference 
focus needs to obtain information about associations between 
floors and resources in order to be able to provide this 
information to a floor participant in an SDP offer/answer 
exchange. 


Other mechanisms for obtaining this information, including discussion 


of how the information is made available to a (SIP) Focus, are 
described in the XCON framework [10] (and other related documents). 
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3.4. Privileges of Floor Control 


A participant whose floor request is granted has the right to use (in 
a certain way) the resource or resources associated with the floor 
that was requested. For example, the participant may have the right 
to send media over a particular audio stream. 


Nevertheless, holding a floor does not imply that others will not be 
able to use its associated resources at the same time, even if they 
do not have the right to do so. Determination of which media 
participants can actually use the resources in the conference is 
discussed in the XCON Framework [10]. 


4. Overview of Operation 


This section provides a non-normative description of BFCP operations. 
Section 4.1 describes the interface between floor participants and 
floor control servers, and Section 4.2 describes the interface 
between floor chairs and floor control servers. 


BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 
consist of a common header followed by a set of attributes. The 
common header contains, among other information, a 32-bit conference 
identifier. Floor participants, media participants, and floor chairs 
are identified by 16-bit user identifiers. 


BFCP supports nested attributes (i.e., attributes that contain 
attributes). These are referred to as grouped attributes. 


There are two types of transactions in BFCP: client-initiated 
transactions and server-initiated transactions. Client-initiated 
transactions consist of a message from a client to the floor control 
server and a response from the floor control server to the client. 
Both messages can be related because they carry the same Transaction 
ID value in their common headers. Server-initiated transactions 
consist of a single message, whose Transaction ID is 0, from the 
floor control server to a client. 


4.1. Floor Participant to Floor Control Server Interface 


Floor participants request a floor by sending a FloorRequest message 
to the floor control server. BFCP supports third-party floor 
requests. That is, the floor participant sending the floor request 
need not be colocated with the media participant that will get the 
floor once the floor request is granted. FloorRequest messages carry 
the identity of the requester in the User ID field of the common 
header, and the identity of the beneficiary of the floor (in third- 
party floor requests) in a BENEFICIARY-ID attribute. 
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Third-party floor requests can be sent, for example, by floor 
participants that have a BFCP connection to the floor control 
server but that are not media participants (i.e., they do not 
handle any media). 


FloorRequest messages identify the floor or floors being requested by 
carrying their 16-bit floor identifiers in FLOOR-ID attributes. Ifa 
FloorRequest message carries more than one floor identifier, the 
floor control server treats all the floor requests as an atomic 
package. That is, the floor control server either grants or denies 
all the floors in the FloorRequest message. 


Floor control servers respond to FloorRequest messages with 
FloorRequestStatus messages, which provide information about the 
status of the floor request. The first FloorRequestStatus message is 
the response to the FloorRequest message from the client, and 
therefore has the same Transaction ID as the FloorRequest. 


Additionally, the first FloorRequestStatus message carries the Floor 
Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 
FloorRequestStatus messages related to the same floor request will 
carry the same Floor Request ID. This way, the floor participant can 
associate them with the appropriate floor request. 


Messages from the floor participant related to a particular floor 
request also use the same Floor Request ID as the first 


FloorRequestStatus Message from the floor control server. 


Figure 2 shows how a floor participant requests a floor, obtains it, 


and, at a later time, releases it. This figure illustrates the use, 
among other things, of the Transaction ID and the FLOOR-REQUEST-ID 
attribute. 
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Floor Participant Floor Control 
Server 

(1) FloorRequest 

Transaction ID: 123 

|User ID: 234 

|FLOOR-ID: 543 


(2) FloorRequestStatus 
Transaction ID: 123 

|User ID: 234 

| FLOOR-REQUEST-INFORMATION 

| Floor Request ID: 789 
| OVERALL-REQUEST-STATUS 

| Request Status: Pending 
| FLOOR-REQUEST-STATUS 
| 

| 

| 


Floor ID: 543 


| 
| 
| 
| 
| 
| 
| 
| 
| 
(3) FloorRequestStatus 
|Transaction ID: 0 | 
User ID: 234 
FLOOR-REQUEST-INFORMATION 
Floor Request ID: 789 | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 

| OVERALL-REQUEST-STATUS 

| Request Status: Accepted 

| Queue Position: 1st 
FLOOR-REQUEST-STATUS 

| Floor ID: 543 

| 

| 

| 


(4) FloorRequestStatus 
|Transaction ID: 0 
User ID: 234 
FLOOR-REQUEST-INFORMATION 


| Floor Request ID: 789 

| OVERALL-REQUEST-STATUS 

| Request Status: Granted 
| FLOOR-REQUEST-STATUS 

Floor ID: 543 


| (5) FloorRelease 
|Transaction ID: 154 
|User ID: 234 
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| 

| (6) FloorRequestStatus | 

Transaction ID: 154 | 

User ID: 234 

| FLOOR-REQUEST-INFORMATION 

Floor Request ID: 789 | 
| 
| 


OVERALL-REQUEST-STATUS 
Request Status: Released 
FLOOR-REQUEST-STATUS 
Floor ID: 543 


Figure 2: Requesting and releasing a floor 


Figure 3 shows how a floor participant requests to be informed on the 
status of a floor. The first FloorStatus message from the floor 
control server is the response to the FloorQuery message and, as 
such, has the same Transaction ID as the FloorQuery message. 


Subsequent FloorStatus messages consist of server-initiated 


transactions, and therefore their Transaction ID is 0. FloorStatus 
message (2) indicates that there are currently two floor requests for 
the floor whose Floor ID is 543. FloorStatus message (3) indicates 


that the floor requests with Floor Request ID 764 has been granted, 
and the floor request with Floor Request ID 635 is the first in the 
queue. FloorStatus message (4) indicates that the floor request with 
Floor Request ID 635 has been granted. 


Floor Participant Floor Control 
Server 
| (1) FloorQuery | 
[Transaction ID: 257 | 
|User ID: 234 
FLOOR-ID: 543 
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| (2) FloorStatus 

Transaction ID: 257 

User ID: 234 

| FLOOR-ID:543 

| FLOOR-REQUEST- INFORMATION 

| Floor Request ID: 764 

| OVERALL-REQUEST-STATUS 

| Request Status: Accepted 
Queue Position: 1st 

| FLOOR-REQUEST-STATUS 

| Floor ID: 543 

| BENEFICIARY-INFORMATION 

| Beneficiary ID: 124 

| FLOOR-REQUEST-INFORMATION 

| Floor Request ID: 635 

| 

| 

| 

| 

| 

| 

| 


OVERALL-REQUEST-STATUS 
Request Status: Accepted 
Queue Position: 2nd 
FLOOR-REQUEST-STATUS 
Floor ID: 543 
BENEFICIARY-INFORMATION 
Beneficiary ID: 154 


(3) FloorStatus 
[Transaction ID: 0 
User ID: 234 
FLOOR-ID:543 
| FLOOR-REQUEST- INFORMATION 
Floor Request ID: 764 
OVERALL-REQUEST-STATUS 
Request Status: Granted 
FLOOR-REQUEST-STATUS 
Floor ID: 543 
BENEFICIARY-INFORMATION 
Beneficiary ID: 124 
FLOOR-REQUEST-INFORMATION 
Floor Request ID: 635 
OVERALL-REQUEST-STATUS 
Request Status: Accepted 
Queue Position: 1st 
FLOOR-REQUEST-STATUS 
Floor ID: 543 
BENEFICIARY-INFORMATION 
Beneficiary ID: 154 
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| 

| (4) FloorStatus | 

Transaction ID: 0 

User ID: 234 

|FLOOR-ID:543 | 

| FLOOR-REQUEST-INFORMATION 

Floor Request ID: 635 
| 
| 
| 
| 


OVERALL-REQUEST-STATUS 
Request Status: Granted 
FLOOR-REQUEST-STATUS 
Floor ID: 543 
BENEFICIARY-INFORMATION 
Beneficiary ID: 154 


Figure 3: Obtaining status information about a floor 


FloorStatus messages contain information about the floor requests 
they carry. For example, FloorStatus message (4) indicates that the 
floor request with Floor Request ID 635 has as the beneficiary (i.e., 
the participant that holds the floor when a particular floor request 
is granted) the participant whose User ID is 154. The floor request 
applies only to the floor whose Floor ID is 543. That is, this is 
not a multi-floor floor request. 


A multi-floor floor request applies to more than one floor (e.g., 
a participant wants to be able to speak and write on the 
whiteboard at the same time). The floor control server treats a 
multi-floor floor request as an atomic package. That is, the 
floor control server either grants the request for all floors or 
denies the request for all floors. 


4.2. Floor Chair to Floor Control Server Interface 


Figure 4 shows a floor chair instructing a floor control server to 
grant a floor. 


Note, however, that although the floor control server needs to 
take into consideration the instructions received in ChairAction 
messages (e.g., granting a floor), it does not necessarily need to 
perform them exactly as requested by the floor chair. The 
operation that the floor control server performs depends on the 
ChairAction message and on the internal state of the floor control 
server. 
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For example, a floor chair may send a ChairAction message granting a 

floor that was requested as part of an atomic floor request operation 
that involved several floors. Even if the chair responsible for one 

of the floors instructs the floor control server to grant the floor, 

the floor control server will not grant it until the chairs 


responsible for the other floors agree to grant them as well. In 
another example, a floor chair may instruct the floor control server 
to grant a floor to a participant. The floor control server needs to 


revoke the floor from its current holder before granting it to the 
new participant. 


So, the floor control server is ultimately responsible for keeping a 
coherent floor state using instructions from floor chairs as input to 
this state. 


Floor Chair Floor Control 
Server 
| (1) ChairAction | 
|Transaction ID: 769 | 
|User ID: 357 | 
| FLOOR-REQUEST-INFORMATION 
Floor Request ID: 635 
| FLOOR-REQUEST-STATUS 
| Floor ID: 543 | 
| Request Status: Granted 
| 
| 


(2) ChairActionAck 
Transaction ID: 769 
[User ID: 357 


Figure 4: Chair instructing the floor control server 
5. Packet Format 
BFCP packets consist of a 12-octet common header followed by 


attributes. All the protocol values MUST be sent in network byte 
order. 
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5.1. COMMON-HEADER Format 
The following is the format of the common header. 


0 1 2 3 
0123456789012345678°9012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Ver | Reserved | Primitive | Payload Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Conference ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Transaction ID User ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: COMMON-HEADER format 


Ver: The 3-bit version field MUST be set to 1 to indicate this 
version of BFCP. 


Reserved: At this point, the 5 bits in the reserved field SHOULD be 
set to zero by the sender of the message and MUST be ignored by the 
receiver. 


Primitive: This 8-bit field identifies the main purpose of the 
message. The following primitive values are defined: 


+------- A t t A SERGE he +++ 222 + 
| Value | Primitive | Direction 
Ho === $ e E $ + 
| 1 | FloorRequest | P -> Ss 
| 2 | FloorRelease | P -> S 
| 3 | FloorRequestQuery | P -> S ; Ch —> S | 
| 4 | FloorRequestStatus | P <- S ; Ch <- S | 
| 5 | UserQuery | P -> S ; Ch —> S | 
6 UserStatus P <- S ; Ch <- 8 
| 7 | FloorQuery | POSO AS | 
| 8 | FloorStatus | P<- S; Ch<-s| 
| 9 | ChairAction | Ch -> s 
| 10 | ChairActionAck | Ch <- s 
t? | Hello P -> S ; Ch —> S 
| 12 HelloAck P <- S$; Ch <- S 
| 13 | Error (PRES ehs] 
+------— $ EE EE $ + 
S: Floor Control Server 
P: Floor Participant 


Ch: Floor Chair 


Table 1: BFCP primitives 
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Payload Length: This 16-bit field contains the length of the message 
in 4-octet units, excluding the common header. 


Conference ID: This 32-bit field identifies the conference the 
message belongs to. 


Transaction ID: This field contains a 16-bit value that allows users 
to match a given message with its response. The value of the 
Transaction ID in server-initiated transactions is 0 (see Section 8). 


User ID: This field contains a 16-bit value that uniquely identifies 
a participant within a conference. 


The identity used by a participant in BFCP, which is carried in 
the User ID field, is generally mapped to the identity used by the 
same participant in the session establishment protocol (e.g., in 
SIP). The way this mapping is performed is outside the scope of 
this specification. 


5.2. Attribute Format 


BFCP attributes are encoded in TLV (Type-Length-Value) format. 
Attributes are 32-bit aligned. 


0 1 2 3 
01234567890123456789012345678090m1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type |m] Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
/ Attribute Contents / 
/ / 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 6: Attribute format 
Type: This 7-bit field contains the type of the attribute. Each 
attribute, identified by its type, has a particular format. The 


attribute formats defined are: 


Unsigned16: The contents of the attribute consist of a 16-bit 
unsigned integer. 


OctetStringl6: The contents of the attribute consist of 16 bits of 
arbitrary data. 
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OctetString: The contents of the attribute consist of arbitrary 
data of variable length. 


Grouped: The contents of the attribute consist of a sequence of 
attributes. 


Note that extension attributes defined in the future may define 
new attribute formats. 


The following attribute types are defined: 


+------ 4--------------------------- 4+--------------- + 
| Type | Attribute | Format | 
4+------ 4--------------------------- 4+--------------- + 
| 1 | BENEFICIARY-ID | Unsigned16 
2 FLOOR-ID | Unsignedl6 | 
| 3 | FLOOR-REQUEST-ID Unsigned16 
| 4 | PRIORITY | OctetStringl6 | 
| 5 | REQUEST-STATUS | OctetStringl6 | 
| 6 | ERROR-CODE | OctetString | 
| 7 | ERROR-INFO | OctetString | 
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 
9 STATUS- INFO OctetString 
| 10 | SUPPORTED-ATTRIBUTES | OctetString 
| 11 | SUPPORTED-PRIMITIVES | OctetString | 
| 12 | USER-DISPLAY-NAME | OctetString 
| 13 | USER-URI | OctetString | 
14 BENEFICIARY-INFORMATION Grouped | 
| 15 | FLOOR-REQUEST-INFORMATION | Grouped 
| 16 | REQUESTED-BY-INFORMATION | Grouped | 
| 17 | FLOOR-REQUEST-STATUS | Grouped | 
| 18 | OVERALL-REQUEST-STATUS | Grouped | 
+------ 4--------------------------- 4+--------------- + 


Table 2: BFCP attributes 


M: The ’M’ bit, known as the Mandatory bit, indicates whether support 
of the attribute is required. If an unrecognized attribute with the 
'M’ bit set is received, the message is rejected. The ’M’ bit is 
significant for extension attributes defined in other documents only. 
All attributes specified in this document MUST be understood by the 
receiver so that the setting of the ’M’ bit is irrelevant for these. 
In all other cases, the unrecognised attribute is ignored but the 
message is processed. 


Length: This 8-bit field contains the length of the attribute in 
octets, excluding any padding defined for specific attributes. The 
length of attributes that are not grouped includes the Type, 'M' bit, 
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and Length fields. The Length in grouped attributes is the length of 
the grouped attribute itself (including Type, 'M” bit, and Length 


fields) plus the total length (including padding) of all the included 
attributes. 


Attribute Contents: The contents of the different attributes are 
defined in the following sections. 


5.2.1. BENEFICIARY-ID 
The following is the format of the BENEFICIARY-ID attribute. 
0 1 2 3 
001 20:34:56: T E 9. OF od 23.4, 516. EBs DO: DB As FB D0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
lo000001|Mjo0000100| Beneficiary ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 7: BENEFICIARY-ID format 


Beneficiary ID: This field contains a 16-bit value that uniquely 
identifies a user within a conference. 


Note that although the formats of the Beneficiary ID and of the 
User ID field in the common header are similar, their semantics 


are different. The Beneficiary ID is used in third-party floor 
requests and to request information about a particular 
participant. 


SAIA FLOOR-ID 
The following is the format of the FLOOR-ID attribute. 
0 1 2 3 
O° 29°45 6 °F 8 99.0 1-9 3.4596. 7-89. 0-2 2 345067 8:90 1 
tata tata tata $ tata ta ta tata ta tata + tata ++ +++ +++ +++ +++ 
lo000010|Mjo0000100| Floor ID 
tata tata ta O + ta tata ta tata tata + + d+ + ++ +++ +++ +++ +++ 


Figure 8: FLOOR-ID format 


Floor ID: This field contains a 16-bit value that uniquely identifies 
a floor within a conference. 
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5.2.3. FLOOR-REQUEST-ID 
The following is the format of the FLOOR-REQUEST-ID attribute. 


0 1 2 3 
01234567890123456789012345678901 
tata tata ta tata tata ta ta tata ta tata + d+ + ++ +++ +++ +++ +++ 

lo000011|MJjo0000100| Floor Request ID 
tata tata tar O tata tata ta tata + + + + d+ + ++ +++ +++ +++ +++ 


Figure 9: FLOOR-REQUEST-ID format 


Floor Request ID: This field contains a 16-bit value that identifies 
a floor request at the floor control server. 


5.2.4. PRIORITY 
The following is the format of the PRIORITY attribute. 


0 1 2 3 
01234567890123 456789012345678901 
tata tata tata tate tata ta tata ta tata + tata ++ +++ +++ +++ +++ 

10 00010 0|Mj0 000010 O|Prio | Reserved 
tata tata A + tarda ta tata tata tata ta tata ++ +++ +++ +++ +++ 


Figure 10: PRIORITY format 


Prio: This field contains a 3-bit priority value, as shown in 

Table 3. Senders SHOULD NOT use values higher than 4 in this field. 
Receivers MUST treat values higher than 4 as if the value received 
were 4 (Highest). The default priority value when the PRIORITY 
attribute is missing is 2 (Normal). 


4+------- 4+---------- + 
| Value | Priority | 
4+------- 4+---------- + 
| 0 | Lowest | 
| 1 | Low | 
| 2 | Normal | 

3 High 

4 Highest 
4+------- 4+---------- + 


Table 3: Priority values 
Reserved: At this point, the 13 bits in the reserved field SHOULD be 


set to zero by the sender of the message and MUST be ignored by the 
receiver. 
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5.2.5. REQUEST-STATUS 
The following is the format of the REQUEST-STATUS attribute. 


0 1 2 3 
01234567890123456789012345678901 
dh ta tata q tata tata tata tata ta ++ + + +++ + +++ ++ +++ 
looo0oo0101|jmjo 00001 0 O|Request Status |Queue Position | 
dh + Ph q E hd + + + + + + ++ ++ ++ + + +++ ++ +++ 


Figure 11: REQUEST-STATUS format 


Request Status: This 8-bit field contains the status of the request, 
as described in the following table. 


io + 
Status | 


+ 

| 

+ 

| Pending | 
| Accepted | 
| Granted | 
| Denied 

Cancelled 

| Released | 
| Revoked 
tes + 


Table 4: Request Status values 


Queue Position: This 8-bit field contains, when applicable, the 
position of the floor request in the floor request queue at the 
server. If the Request Status value is different from Accepted, if 
the floor control server does not implement a floor request queue, or 
if the floor control server does not want to provide the client with 
this information, all the bits of this field SHOULD be set to zero. 


A floor request is in Pending state if the floor control server needs 
to contact a floor chair in order to accept the floor request, but 
has not done it yet. Once the floor control chair accepts the floor 
request, the floor request is moved to the Accepted state. 
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5.2.6. ERROR-CODE 
The following is the format of the ERROR-CODE attribute. 


0 1 2 3 
0123456789012345678°9012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ta O A A A A A A A + + 
lo 00011 ojm] Length | Error Code | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| 

| Error Specific Details 

/ / 
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | Padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


Figure 12: ERROR-CODE format 


Error Code: This 8-bit field contains an error code from the 
following table. If an error code is not recognised by the receiver, 
then the receiver MUST assume that an error exists, and therefore 
that the message is processed, but the nature of the error is 


unclear. 
Ho $ O O O O O O O a + 
| Value | Meaning | 
Ho aS Se A no A eS + 
i Conference does not Exist 
2 User does not Exist 
| 3 | Unknown Primitive | 
| 4 | Unknown Mandatory Attribute 
| 5 | Unauthorized Operation 
| 6 | Invalid Floor ID 
7 Floor Request ID Does Not Exist 
| 8 | You have Already Reached the Maximum Number of Ongoing 
| | Floor Requests for this Floor 
| 9 | Use TLS | 
Ho TE Se ea A A ee ne eee eae ee ee nee + 
Table 5: Error Code meaning 
Error Specific Details: Present only for certain Error Codes. In 


this document, only for Error Code 4 (Unknown Mandatory Attribute). 
See Section 5.2.6.1 for its definition. 


Padding: One, two, or three octets of padding added so that the 


contents of the ERROR-CODE attribute is 32-bit aligned. If the 
attribute is already 32-bit aligned, no padding is needed. 
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The Padding bits SHOULD be set to zero by the sender and MUST be 
ignored by the receiver. 


5.2.6.1. Error-Specific Details for Error Code 4 


The following is the format of the Error-Specific Details field for 
Error Code 4. 


0 1 2 3 

0: I-22 3°45 6: 18:90 12.3 4-5 6° 7 89 OP 1 23 A567 38. 90: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TEELE es gig a Sy ate 
| | Unknown Type|R| Unknown Type|R| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Unknown Type|R| Unknown Type|R| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 13: Unknown attributes format 


Unknown Type: These 7-bit fields contain the Types of the attributes 
(which were present in the message that triggered the Error message) 
that were unknown to the receiver. 


R: At this point, this bit is reserved. It SHOULD be set to zero by 
the sender of the message and MUST be ignored by the receiver. 


5.2.7.  ERROR-INFO 


The following is the format of the ERROR-INFO attribute. 


0 1 2 3 
Od > 3045 6 1708-90 10238. 4 5060 78:90: 13048. 1:89 01 
+ hh RO A dd de de e de de de dd dd de 4 4 4 4 + + + +++ ++ +++ 
lo o.0.0 11 1|m] Length | | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| | 
/ Text / 
/ +-+-+-+-+-+-+-+-+ 
| Padding 

$ hh A RO dd de de de de de de dd dd de 4 4 4 4 + + + +++ ++ +++ 


Figure 14: ERROR-INFO format 


Text: This field contains UTF-8 [6] encoded text. 
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In some situations, the contents of the Text field may be generated 
by an automaton. If this automaton has information about the 
preferred language of the receiver of a particular ERROR-INFO 
attribute, it MAY use this language to generate the Text field. 


Padding: One, two, or three octets of padding added so that the 
contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 
bits SHOULD be set to zero by the sender and MUST be ignored by the 
receiver. If the attribute is already 32-bit aligned, no padding is 
needed. 


5.2.8. PARTICIPANT-PROVIDED-INFO 


The following is the format of the PARTICIPANT-PROVIDED-INFO 
attribute. 


0 1 2 3 
01234567890123456789012345678901 

tata tata tar A ta tata tata tata ta tata ta tata ++ +++ +++ +++ +++ 
lo 00100 ojm] Length | | 

a 

| | 
/ Text / 
/ +-+-+-+-+-+-+-+-+ 
| Padding 

tata tata ta tata ta tata ta tata ta tata ta tata ++ +++ +++ +++ +++ 


Figure 15: PARTICIPANT-PROVIDED-INFO format 
Text: This field contains UTF-8 [6] encoded text. 
Padding: One, two, or three octets of padding added so that the 
contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 
aligned. The Padding bits SHOULD be set to zero by the sender and 


MUST be ignored by the receiver. If the attribute is already 32-bit 
aligned, no padding is needed. 
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5.2.9. STATUS-INFO 
The following is the format of the STATUS-INFO attribute. 


0 1 2 3 
01234567890123456789012345678901 

tata A tata tata dd tata tata ta tata + tata ta tata tata +++ +++ +++ 
lo 00100 1|M| Length | | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 

| 

/ Text / 
/ +-+-+-+-+-+-+-+-+ 
| Padding 

PR A AO A e + e + d+ + + + + + d+ + ++ +++ +++ +++ +++ 


Figure 16: STATUS-INFO format 
Text: This field contains UTF-8 [6] encoded text. 


In some situations, the contents of the Text field may be generated 
by an automaton. If this automaton has information about the 
preferred language of the receiver of a particular STATUS-INFO 
attribute, it MAY use this language to generate the Text field. 


Padding: One, two, or three octets of padding added so that the 
contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 
bits SHOULD be set to zero by the sender and MUST be ignored by the 
receiver. If the attribute is already 32-bit aligned, no padding is 
needed. 


5.2.10. SUPPORTED-ATTRIBUTES 
The following is the format of the SUPPORTED-ATTRIBUTES attribute. 


0 1 2 3 

0 1-23 45607589 00: 1203, D O T 8s OPO? TD Be A Or 879100. 1 
Hd hh + + + q + + q + + +++ ++ +++ ++ +++ +++++>3+ 
lo 00101 ojm] Length | Supp. Attr. |R| Supp. Attr. |R] 
+-+-4+-4+-—4+-4+-4+-4+-4+-4+-4t-4-4+-t-4t-4+-4t-t-4t-4+-t-t-4+-4t-t-4-4+-4t-4t-4+-4t-4t-4+ 
| Supp. Attr. |R] Supp. Attr. |R] Supp. Attr. |R] Supp. Attr. |R] 
dd + + + q + + q + + + + + +H 
| | 
/ / 
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Padding | 
dd dh + + + + + + + + + + +++ 


Figure 17: SUPPORTED-ATTRIBUTES format 
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Supp. Attr.: These fields contain the Types of the attributes that 
are supported by the floor control server in the following format: 


R: Reserved: This bit MUST be set to zero upon transmission and MUST 
be ignored upon reception. 


Padding: Two octets of padding added so that the contents of the 
SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute 
is already 32-bit aligned, no padding is needed. 


The Padding bits SHOULD be set to zero by the sender and MUST be 
ignored by the receiver. 


5.2.11. SUPPORTED-PRIMITIVES 
The following is the format of the SUPPORTED-PRIMITIVES attribute. 
0 1 2 3 


01.2 34.535.6 789012345618 901 2.34 5.6 78901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


|o 00101 1|m| Length | Primitive | Primitive | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Primitive | Primitive | Primitive | Primitive | 


E A O O O O O O O O O A O O O o o o o ++ 
/ / 
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


Figure 18: SUPPORTED-PRIMITIVES format 
Primitive: These fields contain the types of the BFCP messages that 
are supported by the floor control server. See Table 1 for the list 
of BFCP primitives. 
Padding: One, two, or three octets of padding added so that the 
contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 
the attribute is already 32-bit aligned, no padding is needed. 


The Padding bits SHOULD be set to zero by the sender and MUST be 
ignored by the receiver. 
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5.2.12. USER-DISPLAY-NAME 
The following is the format of the USER-DISPLAY-NAME attribute. 


0 1 2 3 
01234567890123456789012345678901 
tata tata A A tata tata tata ta ta tata + + + ++ +++ +++ +++ +++ 

lo 00110 ojm] Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 

| 

/ Text / 
/ +-+-+-+-+-+-+-+-+ 
| Padding 
PRA A A + e + e + $ + tata ta tata ++ +++ +++ +++ +++ 


Figure 19: USER-DISPLAY-NAME format 
Text: This field contains the UTF-8 encoded name of the user. 


Padding: One, two, or three octets of padding added so that the 
contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 
Padding bits SHOULD be set to zero by the sender and MUST be ignored 
by the receiver. If the attribute is already 32-bit aligned, no 
padding is needed. 


5.2.13. USER-URI 
The following is the format of the USER-URI attribute. 


0 1 2 3 
FA DABA O A OO ABAD OA 
+ hh RO A q de de de e de de de dd dd de 4 4 4 4 + + + ++ +++ +++ 

}o001101|M| Length | 
+—4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4-+ 

| 

/ Text / 
/ +-+-+-+-+-+-+-+-+ 
| Padding 

$ hh RO A dd de de e e de de dd dd de 4 4 4 4 + + + + + +++ +++ 


Figure 20: USER-URI format 


Text: This field contains the UTF-8 encoded user's contact URI, that 
is, the URI used by the user to set up the resources (e.g., media 
streams) that are controlled by BFCP. For example, in the context of 
a conference set up by SIP, the USER-URI attribute would carry the 
SIP URI of the user. 
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Messages containing a user’s URI in a USER-URI attribute also 
contain the user’s User ID. This way, a client receiving such a 
message can correlate the user’s URI (e.g., the SIP URI the user 
used to join a conference) with the user’s User ID. 


Padding: One, two, or three octets of padding added so that the 
contents of the USER-URI attribute is 32-bit aligned. The Padding 
bits SHOULD be set to zero by the sender and MUST be ignored by the 
receiver. If the attribute is already 32-bit aligned, no padding is 
needed. 


5.2.14. BENEFICIARY-INFORMATION 


The BENEFICIARY-INFORMATION attribute is a grouped attribute that 
consists of a header, which is referred to as BENEFICIARY- 
INFORMATION-HEADER, followed by a sequence of attributes. The 
following is the format of the BENEFICIARY-INFORMATION-HEADER: 


0 1 2 3 

(OA INS SE ESTO 6. Fo BGO. ESE 56 Be 90. D2) 0 S60 FB: Qe ES 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o 00111 ojm] Length | Beneficiary ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 21: BENEFICIARY-INFORMATION-HEADER format 


Beneficiary ID: This field contains a 16-bit value that uniquely 
identifies a user within a conference. 


The following is the ABNF (Augmented Backus-Naur Form) [2] of the 
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 
refers to extension attributes that may be defined in the future.) 


BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 
[USER-DISPLAY-NAME] 
[USER-URI] 


* [EXTENSION-ATTRIBUTE] 
Figure 22: BENEFICIARY-INFORMATION format 
AA S FLOOR-REQUEST-INFORMATION 
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 
consists of a header, which is referred to as FLOOR-REQUEST-— 


INFORMATION-HEADER, followed by a sequence of attributes. The 
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 
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0 1 2 3 

001-2:34:5:6: 789012345678 OO 1-2 3456678901 
$ hh A A RO dd e e e de de dd dd de 4 4 4 4 + + + ++ +++ +++ 
lo 0.0.1 1 1 1|]m] Length | Floor Request ID | 
dh hh RO dd dd e de de de dd dd de 4 4 4 4 + + + +++ ++ +++ 


Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 


Floor Request ID: This field contains a 16-bit value that identifies 
a floor request at the floor control server. 


The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 
may be defined in the future.) 


FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 

[OVERALL-REQUEST-STATUS] 

1* (FLOOR-REQUEST-STATUS) 
[BENEF ICIARY-INFORMATION] 
[REQUESTED-BY-INFORMATION] 
[PRIORITY] 
[PARTICIPANT-PROVIDED-INFO] 

* [EXTENSION-ATTRIBUTE] 


Figure 24: FLOOR-REQUEST-INFORMATION format 
5.2.16. REQUESTED-BY-INFORMATION 


The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 
consists of a header, which is referred to as REQUESTED-BY- 
INFORMATION-HEADER, followed by a sequence of attributes. The 
following is the format of the REQUESTED-BY-INFORMATION-HEADER: 


0 1 2 3 
012345678901 23456789012345678090U1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|0 01000 ojm] Length | Requested-by ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 25: REQUESTED-BY-INFORMATION-HEADER format 


Requested-by ID: This field contains a 16-bit value that uniquely 
identifies a user within a conference. 


The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 


attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 
may be defined in the future.) 
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REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 
[USER-DISPLAY-NAME] 
[USER-URI] 
* [EXTENSION-ATTRIBUTE] 


Figure 26: REQUESTED-BY-INFORMATION format 
5.2.17. FLOOR-REQUEST-STATUS 


The FLOOR-REQUEST-STATUS attribute is a grouped attribute that 
consists of a header, which is referred to as 
FLOOR—-REQUEST-STATUS-HEADER, followed by a sequence of attributes. 
The following is the format of the FLOOR-REQUEST-STATUS-HEADER: 


0 1 2 3 
02 34036) F890 A aA Sb 708900: T 34 DO gg OT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|o 01000 1|m| Length | Floor ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 27: FLOOR-REQUEST-STATUS-HEADER format 


Floor ID: this field contains a 16-bit value that uniquely identifies 
a floor within a conference. 


The following is the ABNF of the FLOOR-REQUEST-STATUS grouped 
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 
may be defined in the future.) 


FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) 
[REQUEST-STATUS] 
[STATUS-INFO] 
* [EXTENSION-ATTRIBUTE] 


Figure 28: FLOOR-REQUEST-STATUS format 
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5.2.18. OVERALL-REQUEST-STATUS 


The OVERALL-REQUEST-STATUS attribute is a grouped attribute that 
consists of a header, which is referred to as 
OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. 
The following is the format of the OVERALL-REQUEST-STATUS-HEADER: 


0 1 2 3 

O AA RAT PB COMO. ES O A S68 A DMT AE CIA A 6. FBO: OL 
HA A OA A A A O O AO A A A O O O O A A A A A A + + 
19-02 1:0:-0 160. M1] Length | Floor Request ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


Figure 29: OVERALL-REQUEST-STATUS-HEADER format 


Floor Request ID: this field contains a 16-bit value that identifies 
a floor request at the floor control server. 


The following is the ABNF of the OVERALL-REQUEST-STATUS grouped 
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 
may be defined in the future.) 


OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) 
[REQUEST-STATUS] 
[STATUS-INFO] 
* [EXTENSION-ATTRIBUTE] 
Figure 30: OVERALL-REQUEST-STATUS format 
5.3. Message Format 
This section contains the normative ABNF (Augmented Backus-Naur Form) 


[2] of the BFCP messages. Extension attributes that may be defined 
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 
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5.3.1. FloorRequest 


Floor participants request a floor by sending a FloorRequest message 
to the floor control server. The following is the format of the 
FloorRequest message: 


FloorRequest = (COMMON-HEADER) 
1* (FLOOR-ID) 
[BENEFICIARY-ID] 
[PARTICIPANT-PROVIDED-INFO] 
[PRIORITY] 
* [EXTENSION-ATTRIBUTE] 


Figure 31: FloorRequest format 
5.3.2. FloorRelease 


Floor participants release a floor by sending a FloorRelease message 
to the floor control server. Floor participants also use the 
FloorRelease message to cancel pending floor requests. The following 
is the format of the FloorRelease message: 


FloorRelease = (COMMON-HEADER) 
(FLOOR-REQUEST-ID) 
* [EXTENSION-ATTRIBUTE] 


Figure 32: FloorRelease format 
5.3.3. FloorRequestQuery 
Floor participants and floor chairs request information about a floor 
request by sending a FloorRequestQuery message to the floor control 


server. The following is the format of the FloorRequestQuery 
message: 


FloorRequestQuery = (COMMON-HEADER) 


(FLOOR-REQUEST-ID) 
* [EXTENSION-ATTRIBUTE] 


Figure 33: FloorRequestQuery format 
5.3.4. FloorRequestStatus 
The floor control server informs floor participants and floor chairs 
about the status of their floor requests by sending them 


FloorRequestStatus messages. The following is the format of the 
FloorRequestStatus message: 
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FloorRequestStatus = (COMMON—HEADER) 
(FLOOR-REQUEST-INFORMATION) 
* [EXTENSION-ATTRIBUTE] 


Figure 34: FloorRequestStatus format 
5.3.5. UserQuery 


Floor participants and floor chairs request information about a 
participant and the floor requests related to this participant by 
sending a UserQuery message to the floor control server. The 
following is the format of the UserQuery message: 


UserQuery = (COMMON-HEADER) 
[BENEFICIARY-ID] 
* [EXTENSION-ATTRIBUTE] 


Figure 35: UserQuery format 
5.3.6. UserStatus 


The floor control server provides information about participants and 
their related floor requests to floor participants and floor chairs 
by sending them UserStatus messages. The following is the format of 
the UserStatus message: 


UserStatus = (COMMON-HEADER) 
[BENEFICIARY-INFORMATION] 


* (FLOOR-REQUEST-INFORMATION) 
* [EXTENSION-ATTRIBUTE] 


Figure 36: UserStatus format 
5.3.7. FloorQuery 

Floor participants and floor chairs request information about a floor 
or floors by sending a FloorQuery message to the floor control 
server. The following is the format of the FloorRequest message: 
FloorQuery = (COMMON-HEADER) 

* (FLOOR-ID) 

* [EXTENSION-ATTRIBUTE] 


Figure 37: FloorQuery format 
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5.3.8. FloorStatus 


The floor control server informs floor participants and floor chairs 
about the status (e.g., the current holder) of a floor by sending 
them FloorStatus messages. The following is the format of the 
FloorStatus message: 


FloorStatus = (COMMON-HEADER) 
*1 (FLOOR-ID) 
* [FLOOR-REQUEST- INFORMATION] 
* [EXTENSION-ATTRIBUTE] 
Figure 38: FloorStatus format 


5.3.9. ChairAction 


Floor chairs send instructions to floor control servers by sending 


ChairAction messages. The following is the format of the ChairAction 
message: 
ChairAction = (COMMON-HEADER) 


(FLOOR-REQUEST-INFORMATION) 
* [EXTENSION-ATTRIBUTE] 


Figure 39: ChairAction format 
5.3.10. ChairActionAck 
Floor control servers confirm that they have accepted a ChairAction 
message by sending a ChairActionAck message. The following is the 


format of the ChairActionAck message: 


ChairActionAck = (COMMON-HEADER) 
* [EXTENSION-ATTRIBUTE] 


Figure 40: ChairActionAck format 


5.3.11. Hello 


Floor participants and floor chairs check the liveliness of floor 
control servers by sending a Hello message. The following is the 
format of the Hello message: 


Hello (COMMON-HEADER) 


* [EXTENSION-ATTRIBUTE] 


Figure 41: Hello format 


Camarillo, et al. Standards Track [Page 33] 


RFC 4582 BFCP November 2006 


5.3.12. HelloAck 


Floor control servers confirm that they are alive on reception of a 
Hello message by sending a HelloAck message. The following is the 
format of the HelloAck message: 


HelloAck (COMMON-HEADER) 
(SUPPORTED-PRIMITIVES) 
(SUPPORTED-ATTRIBUTES) 


* [EXTENSION-ATTRIBUTE] 
Figure 42: HelloAck format 
edu Lis: Error 


Floor control servers inform floor participants and floor chairs 
about errors processing requests by sending them Error messages. The 
following is the format of the Error message: 


Error = (COMMON- HEADER) 
(ERROR-CODE) 
[ERROR-INFO] 
* [EXTENSION-ATTRIBUTE] 


Figure 43: Error format 
6. Transport 


BFCP entities exchange BFCP messages using TCP connections. TCP 
provides an in-order reliable delivery of a stream of bytes. 
Consequently, message framing is implemented in the application 
layer. BFCP implements application-layer framing using TLV-encoded 
attributes. 


A client MUST NOT use more than one TCP connection to communicate 
with a given floor control server within a conference. Nevertheless, 
if the same physical box handles different clients (e.g., a floor 
chair and a floor participant), which are identified by different 
User IDs, a separate connection per client is allowed. 


If a BFCP entity (a client or a floor control server) receives data 
from TCP that cannot be parsed, the entity MUST close the TCP 
connection, and the connection SHOULD be reestablished. Similarly, 
if a TCP connection cannot deliver a BFCP message and times out, the 
TCP connection SHOULD be reestablished. 
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The way connection reestablishment is handled depends on how the 
client obtains information to contact the floor control server (e.g., 
using an SDP offer/answer exchange [7]). Once the TCP connection is 
reestablished, the client MAY resend those messages for which it did 
not get a response from the floor control server. 


If a floor control server detects that the TCP connection towards one 
of the floor participants is lost, it is up to the local policy of 
the floor control server what to do with the pending floor requests 
of the floor participant. In any case, it is RECOMMENDED that the 
floor control server keep the floor requests (i.e., that it does not 
cancel them) while the TCP connection is reestablished. 


If a client wishes to end its BFCP connection with a floor control 
server, the client closes (i.e., a graceful close) the TCP connection 
towards the floor control server. If a floor control server wishes 
to end its BFCP connection with a client (e.g., the Focus of the 
conference informs the floor control server that the client has been 
kicked out from the conference), the floor control server closes 
(i.e., a graceful close) the TCP connection towards the client. 


7. Lower-Layer Security 


BFCP relies on lower-layer security mechanisms to provide replay and 
integrity protection and confidentiality. BFCP floor control servers 
and clients (which include both floor participants and floor chairs) 
MUST support TLS [3]. Any BFCP entity MAY support other security 
mechanisms. 


BFCP entities MUST support, at a minimum, the TLS 
TLS_RSA_WITH_AES_128 CBC_SHA ciphersuite [5]. 


Which party, the client or the floor control server, acts as the TLS 
server depends on how the underlying TCP connection is established. 
For example, when the TCP connection is established using an SDP 
offer/answer exchange [7], the answerer (which may be the client or 
the floor control server) always acts as the TLS server. 


8. Protocol Transactions 


In BFCP, there are two types of transactions: client-initiated 
transactions and server-initiated transactions (notifications). 
Client-initiated transactions consist of a request from a client toa 
floor control server and a response from the floor control server to 
the client. The request carries a Transaction ID in its common 
header, which the floor control server copies into the response. 
Clients use Transaction ID values to match responses with previously 
issued requests. 
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Server-initiated transactions consist of a single message from a 
floor control server to a client. Since they do not trigger any 
response, their Transaction ID is set to 0. 


8.1. Client Behavior 


A client starting a client-initiated transaction MUST set the 
Conference ID in the common header of the message to the Conference 
ID for the conference that the client obtained previously. 


The client MUST set the Transaction ID value in the common header to 
a number that is different from 0 and that MUST NOT be reused in 
another message from the client until a response from the server is 
received for the transaction. The client uses the Transaction ID 
value to match this message with the response from the floor control 
server. 


8.2. Server Behavior 


A floor control server sending a response within a client-initiated 
transaction MUST copy the Conference ID, the Transaction ID, and the 
User ID from the request received from the client into the response. 
Server-initiated transactions MUST contain a Transaction ID equal to 
0. 


9. Authentication and Authorization 


BFCP clients SHOULD authenticate the floor control server before 

sending any BFCP message to it or accepting any BFCP message from it. 
Similarly, floor control servers SHOULD authenticate a client before 
accepting any BFCP message from it or sending any BFCP message to it. 


BFCP supports TLS-based mutual authentication between clients and 
floor control servers, as specified in Section 9.1. This is the 
RECOMMENDED authentication mechanism in BFCP. 


Note that future extensions may define additional authentication 
mechanisms. 


In addition to authenticating BFCP messages, floor control servers 
need to authorize them. On receiving an authenticated BFCP message, 
the floor control server checks whether the client sending the 
message is authorized. If the client is not authorized to perform 
the operation being requested, the floor control server generates an 
Error message, as described in Section 13.8, with an Error code with 
a value of 5 (Unauthorized Operation). Messages from a client that 
Cannot be authorized MUST NOT be processed further. 
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9.1. TLS-Based Mutual Authentication 


BFCP supports TLS-based mutual authentication between clients and 
floor control servers. BFCP assumes that there is an integrity- 
protected channel between the client and the floor control server 
that can be used to exchange their self-signed certificates or, more 
commonly, the fingerprints of these certificates. These certificates 
are used at TLS establishment time. 


The implementation of such an integrity-protected channel using 
SIP and the SDP offer/answer model is described in [7]. 


BFCP messages received over an authenticated TLS connection are 
considered authenticated. A floor control server that receives a 
BFCP message over TCP (no TLS) can request the use of TLS by 
generating an Error message, as described in Section 13.8, with an 
Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore 
unauthenticated messages. 


Note that future extensions may define additional authentication 
mechanisms that may not require an initial integrity-protected 
channel (e.g., authentication based on certificates signed by a 
certificate authority). 


As described in Section 9, floor control servers need to perform 
authorization before processing any message. In particular, the 
floor control server SHOULD check that messages arriving over a given 
authenticated TLS connection use an authorized User ID (i.e., a User 
ID that the user that established the authenticated TLS connection is 
allowed to use). 


10. Floor Participant Operations 


This section specifies how floor participants can perform different 
operations, such as requesting a floor, using the protocol elements 
described in earlier sections. Section 11 specifies operations that 
are specific to floor chairs, such as instructing the floor control 
server to grant or revoke a floor, and Section 12 specifies 
operations that can be performed by any client (i.e., both floor 
participants and floor chairs). 


10.1. Requesting a Floor 


A floor participant that wishes to request one or more floors does so 
by sending a FloorRequest message to the floor control server. 
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1.1. Sending a FloorRequest Message 


The ABNF in Section 5.3.1 describes the attributes that a 
FloorRequest message can contain. In addition, the ABNF specifies 
normatively which of these attributes are mandatory, and which ones 
are optional. 


The floor participant sets the Conference ID and the Transaction ID 
in the common header following the rules given in Section 8.1. 


The floor participant sets the User ID in the common header to the 
floor participant’s identifier. This User ID will be used by the 
floor control server to authenticate and authorize the request. If 
the sender of the FloorRequest message (identified by the User ID) is 
not the participant that would eventually get the floor (i.e., a 
third-party floor request), the sender SHOULD add a BENEFICIARY-ID 
attribute to the message identifying the beneficiary of the floor. 


Note that the name space for both the User ID and the Beneficiary 
ID is the same. That is, a given participant is identified by a 
single 16-bit value that can be used in the User ID in the common 
header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 
INFORMATION, and REQUESTED-BY-INFORMATION. 


The floor participant must insert at least one FLOOR-ID attribute in 
the FloorRequest message. If the client inserts more than one 
FLOOR-ID attribute, the floor control server will treat all the floor 
requests as an atomic package. That is, the floor control server 
will either grant or deny all the floors in the FloorRequest message. 


The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 
to state the reason why the floor or floors are being requested. The 
Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 
human consumption. 


The floor participant may request that the server handle the floor 
request with a certain priority using a PRIORITY attribute. 


1.2. Receiving a Response 


A message from the floor control server is considered a response to 
the FloorRequest message if the message from the floor control server 
has the same Conference ID, Transaction ID, and User ID as the 
FloorRequest message, as described in Section 8.1. On receiving such 
a response, the floor participant follows the rules in Section 9 that 
relate to floor control server authentication. 
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The successful processing of a FloorRequest message at the floor 
control server involves generating one or several FloorRequestStatus 
messages. The floor participant obtains a Floor Request ID in the 
Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 
the first FloorRequestStatus message from the floor control server. 
Subsequent FloorRequestStatus messages from the floor control server 
regarding the same floor request will carry the same Floor Request ID 
in a FLOOR-REQUEST-INFORMATION attribute as the initial 
FloorRequestStatus message. This way, the floor participant can 
associate subsequent incoming FloorRequestStatus messages with the 
ongoing floor request. 


The floor participant obtains information about the status of the 
floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 
the FloorRequestStatus messages received from the floor control 
server. This attribute is a grouped attribute, and as such it 
includes a number of attributes that provide information about the 
floor request. 


The OVERALL-REQUEST-STATUS attribute provides information about the 
overall status of the floor request. If the Request Status value is 
Granted, all the floors that were requested in the FloorRequest 
message have been granted. If the Request Status value is Denied, 
all the floors that were requested in the FloorRequest message have 
been denied. A floor request is considered to be ongoing while it is 
in the Pending, Accepted, or Granted states. If the floor request 
value is unknown, then the response is still processed. However, no 
meaningful value can be reported to the user. 


The STATUS-INFO attribute, if present, provides extra information 
that the floor participant MAY display to the user. 


The FLOOR-REQUEST-STATUS attributes provide information about the 
status of the floor request as it relates to a particular floor. The 
STATUS-INFO attribute, if present, provides extra information that 
the floor participant MAY display to the user. 


The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 
the floor request in third-party floor requests. The 
REQUESTED-BY-INFORMATION attribute need not be present in 
FloorRequestStatus messages received by the floor participant that 
requested the floor, as this floor participant is already identified 
by the User ID in the common header. 


The PRIORITY attribute, when present, contains the priority that was 
requested by the generator of the FloorRequest message. 
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If the response is an Error message, the floor control server could 
not process the FloorRequest message for some reason, which is 
described in the Error message. 


10.2. Cancelling a Floor Request and Releasing a Floor 


A floor participant that wishes to cancel an ongoing floor request 
does so by sending a FloorRelease message to the floor control 
server. The FloorRelease message is also used by floor participants 
that hold a floor and would like to release it. 


10.2.1. Sending a FloorRelease Message 


The ABNF in Section 5.3.2 describes the attributes that a 
FloorRelease message can contain. In addition, the ABNF specifies 
normatively which of these attributes are mandatory, and which ones 
are optional. 


The floor participant sets the Conference ID and the Transaction ID 
in the common header following the rules given in Section 8.1. The 
floor participant sets the User ID in the common header to the floor 
participant’s identifier. This User ID will be used by the floor 
control server to authenticate and authorize the request. 


Note that the FloorRelease message is used to release a floor or 
floors that were granted and to cancel ongoing floor requests 
(from the protocol perspective, both are ongoing floor requests). 
Using the same message in both situations helps resolve the race 
condition that occurs when the FloorRelease message and the 
FloorGrant message cross each other on the wire. 


The floor participant uses the FLOOR-REQUEST-ID that was received in 
the response to the FloorRequest message that the FloorRelease 
message is cancelling. 


Note that if the floor participant requested several floors as an 
atomic operation (i.e., in a single FloorRequest message), all the 
floors are released as an atomic operation as well (i.e., all are 
released at the same time). 


10.2.2. Receiving a Response 


A message from the floor control server is considered a response to 
the FloorRelease message if the message from the floor control server 
has the same Conference ID, Transaction ID, and User ID as the 
FloorRequest message, as described in Section 8.1. On receiving such 
a response, the floor participant follows the rules in Section 9 that 
relate to floor control server authentication. 
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If the response is a FloorRequestStatus message, the Request Status 
value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- 
REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. 


If the response is an Error message, the floor control server could 
not process the FloorRequest message for some reason, which is 
described in the Error message. 


It is possible that the FloorRelease message crosses on the wire with 
a FloorRequestStatus message from the server with a Request Status 
different from Cancelled or Released. In any case, such a 
FloorRequestStatus message will not be a response to the FloorRelease 
message, as its Transaction ID will not match that of the 
FloorRelease. 


Chair Operations 


This section specifies how floor chairs can instruct the floor 
control server to grant or revoke a floor using the protocol elements 
described in earlier sections. 


Floor chairs that wish to send instructions to a floor control server 
do so by sending a ChairAction message. 


1. Sending a ChairAction Message 


The ABNF in Section 5.3.9 describes the attributes that a ChairAction 
message can contain. In addition, the ABNF specifies normatively 
which of these attributes are mandatory, and which ones are optional. 


The floor chair sets the Conference ID and the Transaction ID in the 
common header following the rules given in Section 8.1. The floor 
chair sets the User ID in the common header to the floor 
participant’s identifier. This User ID will be used by the floor 
control server to authenticate and authorize the request. 


The ChairAction message contains instructions that apply to one or 
more floors within a particular floor request. The floor or floors 
are identified by the FLOOR-REQUEST-STATUS attributes and the floor 
request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which 
are carried in the ChairAction message. 


For example, if a floor request consists of two floors that depend on 
different floor chairs, each floor chair will grant its floor within 
the floor request. Once both chairs have granted their floor, the 
floor control server will grant the floor request as a whole. On the 
other hand, if one of the floor chairs denies its floor, the floor 
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control server will deny the floor request as a whole, regardless of 
the other floor chair’s decision. 


The floor chair provides the new status of the floor request as it 
relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. 
If the new status of the floor request is Accepted, the floor chair 
MAY use the Queue Position field to provide a queue position for the 
floor request. If the floor chair does not wish to provide a queue 
position, all the bits of the Queue Position field SHOULD be set to 
zero. The floor chair SHOULD use the Status Revoked to revoke a 
floor that was granted (i.e., Granted status) and SHOULD use the 
Status Denied to reject floor requests in any other status (e.g., 
Pending and Accepted). 


The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the 
ChairAction message to provide a new overall status for the floor 
request. If the new overall status of the floor request is Accepted, 
the floor chair MAY use the Queue Position field to provide a queue 
position for the floor request. 


Note that a particular floor control server may implement a 
different queue for each floor containing all the floor requests 
that relate to that particular floor, a general queue for all 
floor requests, or both. Also note that a floor request may 
involve several floors and that a ChairAction message may only 
deal with a subset of these floors (e.g., if a single floor chair 
is not authorized to manage all the floors). In this case, the 
floor control server will combine the instructions received from 
the different floor chairs in FLOOR-REQUEST-STATUS attributes to 
come up with the overall status of the floor request. 


Note that, while the action of a floor chair may communicate 
information in the OVERALL-REQUEST-STATUS attribute, the floor 
control server may override, modify, or ignore this field's 
content. 


The floor chair may use STATUS-INFO attributes to state the reason 
why the floor or floors are being accepted, granted, or revoked. The 
Text in the STATUS-INFO attribute is intended for human consumption. 


.2. Receiving a Response 


A message from the floor control server is considered a response to 
the ChairAction message if the message from the server has the same 
Conference ID, Transaction ID, and User ID as the ChairAction 
message, as described in Section 8.1. On receiving such a response, 
the floor chair follows the rules in Section 9 that relate to floor 
control server authentication. 
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A ChairActionAck message from the floor control server confirms that 
the floor control server has accepted the ChairAction message. An 
Error message indicates that the floor control server could not 
process the ChairAction message for some reason, which is described 
in the Error message. 


General Client Operations 


This section specifies operations that can be performed by any 
client. That is, they are not specific to floor participants or 
floor chairs. They can be performed by both. 


1. Requesting Information about Floors 


A client can obtain information about the status of a floor or floors 
in different ways, which include using BFCP and using out-of-band 
mechanisms. Clients using BFCP to obtain such information use the 
procedures described in this section. 


Clients request information about the status of one or several floors 
by sending a FloorQuery message to the floor control server. 


1.1. Sending a FloorQuery Message 


The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 
message can contain. In addition, the ABNF specifies normatively 
which of these attributes are mandatory, and which ones are optional. 


The client sets the Conference ID and the Transaction ID in the 
common header following the rules given in Section 8.1. The client 
sets the User ID in the common header to the client’s identifier. 
This User ID will be used by the floor control server to authenticate 
and authorize the request. 


The client inserts in the message all the Floor IDs it wants to 
receive information about. The floor control server will send 
periodic information about all of these floors. If the client does 
not want to receive information about a particular floor any longer, 
it sends a new FloorQuery message removing the FLOOR-ID of this 
floor. If the client does not want to receive information about any 
floor any longer, it sends a FloorQuery message with no FLOOR-ID 
attribute. 


1.2. Receiving a Response 
A message from the floor control server is considered a response to 


the FloorQuery message if the message from the floor control server 
has the same Conference ID, Transaction ID, and User ID as the 
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FloorRequest message, as described in Section 8.1. On receiving such 
a response, the client follows the rules in Section 9 that relate to 
floor control server authentication. 


On reception of the FloorQuery message, the floor control server will 
respond with a FloorStatus message or with an Error message. If the 
response is a FloorStatus message, it will contain information about 
one of the floors the client requested information about. If the 
client did not include any FLOOR-ID attribute in its FloorQuery 
message (i.e., the client does not want to receive information about 
any floor any longer), the FloorStatus message from the floor control 
server will not include any FLOOR-ID attribute either. 


FloorStatus messages that carry information about a floor contain a 
FLOOR-ID attribute that identifies the floor. After this attribute, 
FloorStatus messages contain information about existing (one or more) 
floor requests that relate to that floor. The information about each 
particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 
attribute. This grouped attribute carries a Floor Request ID that 
identifies the floor request, followed by a set of attributes that 
provide information about the floor request. 


After the first FloorStatus, the floor control server will continue 
sending FloorStatus messages, periodically informing the client about 
changes on the floors the client requested information about. 


-2. Requesting Information about Floor Requests 


A client can obtain information about the status of one or several 
floor requests in different ways, which include using BFCP and using 
out-of-band mechanisms. Clients using BFCP to obtain such 
information use the procedures described in this section. 


Clients request information about the current status of a floor 
request by sending a FloorRequestQuery message to the floor control 
server. 


Requesting information about a particular floor request is useful in 
a number of situations. For example, on reception of a FloorRequest 
message, a floor control server may choose to return 
FloorRequestStatus messages only when the floor request changes its 
state (e.g., from Accepted to Granted), but not when the floor 
request advances in its queue. In this situation, if the user 
requests it, the floor participant can use a FloorRequestQuery 
message to poll the floor control server for the status of the floor 
request. 
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.2.1. Sending a FloorRequestQuery Message 


The ABNF in Section 5.3.3 describes the attributes that a 
FloorRequestQuery message can contain. In addition, the ABNF 
specifies normatively which of these attributes are mandatory, and 
which ones are optional. 


The client sets the Conference ID and the Transaction ID in the 
common header following the rules given in Section 8.1. The client 
sets the User ID in the common header to the client’s identifier. 
This User ID will be used by the floor control server to authenticate 
and authorize the request. 


The client must insert a FLOOR-REQUEST-ID attribute that identifies 
the floor request at the floor control server. 


.2.2. Receiving a Response 


A message from the floor control server is considered a response to 
the FloorRequestQuery message if the message from the floor control 
server has the same Conference ID, Transaction ID, and User ID as the 
FloorRequestQuery message, as described in Section 8.1. On receiving 
such a response, the client follows the rules in Section 9 that 
relate to floor control server authentication. 


If the response is a FloorRequestStatus message, the client obtains 
information about the status of the FloorRequest the client requested 
information about in a FLOOR-REQUEST-INFORMATION attribute. 


If the response is an Error message, the floor control server could 
not process the FloorRequestQuery message for some reason, which is 
described in the Error message. 


3. Requesting Information about a User 


A client can obtain information about a participant and the floor 
requests related to this participant in different ways, which include 
using BFCP and using out-of-band mechanisms. Clients using BFCP to 
obtain such information use the procedures described in this section. 


Clients request information about a participant and the floor 
requests related to this participant by sending a UserQuery message 
to the floor control server. 


This functionality may be useful for floor chairs or floor 
participants interested in the display name and the URI of a 
particular floor participant. In addition, a floor participant may 
find it useful to request information about itself. For example, a 
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floor participant, after experiencing connectivity problems (e.g., 
its TCP connection with the floor control server was down for a while 
and eventually was re-established), may need to request information 
about all the floor requests associated to itself that still exist. 


3.1. Sending a UserQuery Message 
The ABNF in Section 5.3.5 describes the attributes that a UserQuery 


message can contain. In addition, the ABNF specifies normatively 
which of these attributes are mandatory, and which ones are optional. 


The client sets the Conference ID and the Transaction ID in the 
common header following the rules given in Section 8.1. The client 
sets the User ID in the common header to the client's identifier. 
This User ID will be used by the floor control server to authenticate 
and authorize the request. 


If the floor participant the client is requesting information about 
is not the client issuing the UserQuery message (which is identified 
by the User ID in the common header of the message), the client MUST 
insert a BENEFICIARY-ID attribute. 


3.2. Receiving a Response 


A message from the floor control server is considered a response to 
the UserQuery message if the message from the floor control server 
has the same Conference ID, Transaction ID, and User ID as the 
UserQuery message, as described in Section 8.1. On receiving such a 
response, the client follows the rules in Section 9 that relate to 
floor control server authentication. 


If the response is a UserStatus message, the client obtains 
information about the floor participant in a BENEFICIARY-INFORMATION 
grouped attribute and about the status of the floor requests 
associated with the floor participant in FLOOR-REQUEST-INFORMATION 
attributes. 


If the response is an Error message, the floor control server could 
not process the UserQuery message for some reason, which is described 
in the Error message. 


4. Obtaining the Capabilities of a Floor Control Server 
A client that wishes to obtain the capabilities of a floor control 


server does so by sending a Hello message to the floor control 
server. 
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4.1. Sending a Hello Message 


The ABNF in Section 5.3.11 describes the attributes that a Hello 
message can contain. In addition, the ABNF specifies normatively 
which of these attributes are mandatory, and which ones are optional. 


The client sets the Conference ID and the Transaction ID in the 
common header following the rules given in Section 8.1. The client 
sets the User ID in the common header to the client’s identifier. 
This User ID will be used by the floor control server to authenticate 
and authorize the request. 


4.2. Receiving Responses 


A message from the floor control server is considered a response to 
the Hello message by the client if the message from the floor control 
server has the same Conference ID, Transaction ID, and User ID as the 
Hello message, as described in Section 8.1. On receiving such a 
response, the client follows the rules in Section 9 that relate to 
floor control server authentication. 


If the response is a HelloAck message, the floor control server could 
process the Hello message successfully. The SUPPORTED-PRIMITVIES and 
SUPPORTED-ATTRIBUTES attributes indicate which primitives and 
attributes, respectively, are supported by the server. 


If the response is an Error message, the floor control server could 
not process the Hello message for some reason, which is described in 
the Error message. 


Floor Control Server Operations 


This section specifies how floor control servers can perform 
different operations, such as granting a floor, using the protocol 
elements described in earlier sections. 


On reception of a message from a client, the floor control server 
MUST check whether the value of the Primitive is supported. If it 
does not, the floor control server SHOULD send an Error message, as 
described in Section 13.8, with Error code 3 (Unknown Primitive). 


On reception of a message from a client, the floor control server 
MUST check whether the value of the Conference ID matched an existing 
conference. If it does not, the floor control server SHOULD send an 
Error message, as described in Section 13.8, with Error code 1 
(Conference does not Exist). 
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On reception of a message from a client, the floor control server 
follows the rules in Section 9 that relate to the authentication of 
the message. 


On reception of a message from a client, the floor control server 
MUST check whether it understands all the mandatory (’M’ bit set) 
attributes in the message. If the floor control server does not 
understand all of them, the floor control server SHOULD send an Error 
message, as described in Section 13.8, with Error code 2 
(Authentication Failed). The Error message SHOULD list the 
attributes that were not understood. 


1. Reception of a FloorRequest Message 


On reception of a FloorRequest message, the floor control server 
follows the rules in Section 9 that relate to client authentication 
and authorization. If while processing the FloorRequest message, the 
floor control server encounters an error, it SHOULD generate an Error 
response following the procedures described in Section 13.8. 


BFCP allows floor participants to have several ongoing floor 
requests for the same floor (e.g., the same floor participant can 
occupy more than one position in a queue at the same time). A 
floor control server that only supports a certain number of 
ongoing floor requests per floor participant (e.g., one) can use 
Error Code 8 (You have Already Reached the Maximum Number of 
Ongoing Floor Requests for this Floor) to inform the floor 
participant. 


1.1. Generating the First FloorRequestStatus Message 


The successful processing of a FloorRequest message by a floor 
control server involves generating one or several FloorRequestStatus 
messages, the first of which SHOULD be generated as soon as possible. 
If the floor control server cannot accept, grant, or deny the floor 
request right away (e.g., a decision from a chair is needed), it 
SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- 
STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped 
attribute) of the first FloorRequestStatus message it generates. 


The policy that a floor control server follows to grant or deny 
floors is outside the scope of this document. A given floor 
control server may perform these decisions automatically while 
another may contact a human acting as a chair every time a 
decision needs to be made. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the FloorRequest into the 
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FloorRequestStatus, as described in Section 8.2. Additionally, the 
floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 
attribute to the FloorRequestStatus. The attributes contained in 
this grouped attribute carry information about the floor request. 


The floor control server MUST assign an identifier that is unique 
within the conference to this floor request, and MUST insert it in 
the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 


attribute. This identifier will be used by the floor participant (or 
by a chair or chairs) to refer to this specific floor request in the 
future. 


The floor control server MUST copy the Floor IDs in the FLOOR-ID 
attributes of the FloorRequest into the FLOOR-REQUEST-STATUS 
attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These 
Floor IDs identify the floors being requested (i.e., the floors 
associated with this particular floor request). 


The floor control server SHOULD copy (if present) the contents of the 
BENEFICIARY-ID attribute from the FloorRequest into a 
BENEFICIARY-INFORMATION attribute inside the 
FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor 
control server MAY provide the display name and the URI of the 
beneficiary in this BENEFICIARY-INFORMATION attribute. 


The floor control server MAY provide information about the requester 
of the floor in a REQUESTED-BY-INFORMATION attribute inside the 
FLOOR-REQUEST-INFORMATION grouped attribute. 


The floor control server MAY copy (if present) the PARTICIPANT- 
PROVIDED-INFO attribute from the FloorRequest into the FLOOR- 
REQUEST-INFORMATION grouped attribute. 


Note that this attribute carries the priority requested by the 
participant. The priority that the floor control server assigns 
to the floor request depends on the priority requested by the 
participant and the rights the participant has according to the 
policy of the conference. For example, a participant that is only 
allowed to use the Normal priority may request Highest priority 
for a floor request. In that case, the floor control server would 
ignore the priority requested by the participant. 


The floor control server MAY copy (if present) the 


PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the 
FLOOR-REQUEST-INFORMATION grouped attribute. 
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13.1.2. Generation of Subsequent FloorRequestStatus Messages 


A floor request is considered to be ongoing as long as it is not in 
the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- 
STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped 
attribute) of the first FloorRequestStatus message generated by the 
floor control server did not indicate any of these states, the floor 
control server will need to send subsequent FloorRequestStatus 
messages. 


When the status of the floor request changes, the floor control 
server SHOULD send new FloorRequestStatus messages with the 
appropriate Request Status. The floor control server MUST add a 
FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 
the one sent in the first FloorRequestStatus message to any new 
FloorRequestStatus related to the same floor request. (The Floor 
Request ID identifies the floor request to which the 
FloorRequestStatus applies.) 


The floor control server MUST set the Transaction ID of subsequent 
FloorRequestStatus messages to 0. 


The rate at which the floor control server sends 
FloorRequestStatus messages is a matter of local policy. A floor 
control server may choose to send a new FloorRequestStatus message 
every time the floor request moves in the floor request queue, 
while another may choose only to send a new FloorRequestStatus 
message when the floor request is Granted or Denied. 


The floor control server may add a STATUS-INFO attribute to any of 
the FloorRequestStatus messages it generates to provide extra 
information about its decisions regarding the floor request (e.g., 
why it was denied). 


Floor participants and floor chairs may request to be informed 
about the status of a floor following the procedures in 

Section 12.1. If the processing of a floor request changes the 
status of a floor (e.g., the floor request is granted and 
consequently the floor has a new holder), the floor control server 
needs to follow the procedures in Section 13.5 to inform the 
clients that have requested that information. 


The common header and the rest of the attributes are the same as in 
the first FloorRequestStatus message. 


The floor control server can discard the state information about a 


particular floor request when this reaches a status of Cancelled, 
Released, or Revoked. 
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-2. Reception of a FloorRequestQuery Message 


On reception of a FloorRequestQuery message, the floor control server 
follows the rules in Section 9 that relate to client authentication 
and authorization. If while processing the FloorRequestQuery 
message, the floor control server encounters an error, it SHOULD 
generate an Error response following the procedures described in 
Section 13.8. 


The successful processing of a FloorRequestQuery message by a floor 
control server involves generating a FloorRequestStatus message, 
which SHOULD be generated as soon as possible. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the FloorRequestQuery message into the 
FloorRequestStatus message, as described in Section 8.2. 
Additionally, the floor control server MUST include information about 
the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute 
to the FloorRequestStatus. 


The floor control server MUST copy the contents of the 
FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 
the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 
attribute. 


The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
floors being requested (i.e., the floors associated with the floor 
request identified by the FLOOR-REQUEST-ID attribute). 


The floor control server SHOULD add a BENEFICIARY-ID attribute to the 
FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
beneficiary of the floor request. Additionally, the floor control 
server MAY provide the display name and the URI of the beneficiary in 
this BENEFICIARY-INFORMATION attribute. 


The floor control server MAY provide information about the requester 
of the floor in a REQUESTED-BY-INFORMATION attribute inside the 
FLOOR-REQUEST-INFORMATION grouped attribute. 


The floor control server MAY provide the reason why the floor 
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 


The floor control server MAY also add to the 
FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with 
the Priority value requested for the floor request and a STATUS-INFO 
attribute with extra information about the floor request. 
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The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 
to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 
status of the floor request. The floor control server MAY provide 
information about the status of the floor request as it relates to 
each of the floors being requested in the FLOOR-REQUEST-STATUS 
attributes. 


3. Reception of a UserQuery Message 


On reception of a UserQuery message, the floor control server follows 
the rules in Section 9 that relate to client authentication and 
authorization. If while processing the UserQuery message, the floor 
control server encounters an error, it SHOULD generate an Error 
response following the procedures described in Section 13.8. 


The successful processing of a UserQuery message by a floor control 
server involves generating a UserStatus message, which SHOULD be 
generated as soon as possible. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the UserQuery message into the USerStatus 
message, as described in Section 8.2. 


The sender of the UserQuery message is requesting information about 
all the floor requests associated with a given participant (i.e., the 
floor requests where the participant is either the beneficiary or the 
requester). This participant is identified by a BENEFICIARY-ID 
attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 
User ID in the common header of the UserQuery message. 


The floor control server MUST copy, if present, the contents of the 
BENEFICIARY-ID attribute from the UserQuery message into a 
BENEFICIARY-INFORMATION attribute in the UserStatus message. 
Additionally, the floor control server MAY provide the display name 
and the URI of the participant about which the UserStatus message 
provides information in this BENEFICIARY-INFORMATION attribute. 


The floor control server SHOULD add to the UserStatus message a 
FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 
related to the participant about which the message provides 
information (i.e., the floor requests where the participant is either 
the beneficiary or the requester). For each 
FLOOR-REQUEST-INFORMATION attribute, the floor control server follows 
the following steps. 


The floor control server MUST identify the floor request the 
FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor 
Request ID field of the FLOOR-REQUEST-INFORMATION attribute. 
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The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
floors being requested (i.e., the floors associated with the floor 
request identified by the FLOOR-REQUEST-ID attribute). 


The floor control server SHOULD add a BENEFICIARY-ID attribute to the 
FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
beneficiary of the floor request. Additionally, the floor control 
server MAY provide the display name and the URI of the beneficiary in 
this BENEFICIARY-INFORMATION attribute. 


The floor control server MAY provide information about the requester 
of the floor in a REQUESTED-BY-INFORMATION attribute inside the 
FLOOR-REQUEST-INFORMATION grouped attribute. 


The floor control server MAY provide the reason why the floor 
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 


The floor control server MAY also add to the FLOOR-REQUEST- 
INFORMATION grouped attribute a PRIORITY attribute with the Priority 
value requested for the floor request. 


The floor control server MUST include the current status of the floor 
request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-— 
INFORMATION grouped attribute. The floor control server MAY add a 
STATUS-INFO attribute with extra information about the floor request. 


The floor control server MAY provide information about the status of 
the floor request as it relates to each of the floors being requested 
in the FLOOR-REQUEST-STATUS attributes. 


4. Reception of a FloorRelease Message 


On reception of a FloorRelease message, the floor control server 
follows the rules in Section 9 that relate to client authentication 
and authorization. If while processing the FloorRelease message, the 
floor control server encounters an error, it SHOULD generate an Error 
response following the procedures described in Section 13.8. 


The successful processing of a FloorRelease message by a floor 
control server involves generating a FloorRequestStatus message, 
which SHOULD be generated as soon as possible. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the FloorRelease message into the 
FloorRequestStatus message, as described in Section 8.2. 
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The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 
attribute to the FloorRequestStatus. The attributes contained in 
this grouped attribute carry information about the floor request. 


The FloorRelease message identifies the floor request it applies to 
using a FLOOR-REQUEST-ID. The floor control server MUST copy the 
contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 
message into the Floor Request ID field of the 
FLOOR-REQUEST-INFORMATION attribute. 


The floor control server MUST identify the floors being requested 
(i.e., the floors associated with the floor request identified by the 
FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the 
FLOOR-REQUEST-INFORMATION grouped attribute. 


The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 
to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request 
Status value SHOULD be Released, if the floor (or floors) had been 
previously granted, or Cancelled, if the floor (or floors) had not 
been previously granted. The floor control server MAY add a STATUS- 
INFO attribute with extra information about the floor request. 


5. Reception of a FloorQuery Message 


On reception of a FloorQuery message, the floor control server 
follows the rules in Section 9 that relate to client authentication. 
If while processing the FloorRelease message, the floor control 
server encounters an error, it SHOULD generate an Error response 
following the procedures described in Section 13.8. 


A floor control server receiving a FloorQuery message from a client 
SHOULD keep this client informed about the status of the floors 

identified by FLOOR-ID attributes in the FloorQuery message. Floor 
Control Servers keep clients informed by using FloorStatus messages. 


An individual FloorStatus message carries information about a single 
floor. So, when a FloorQuery message requests information about more 
than one floor, the floor control server needs to send separate 
FloorStatus messages for different floors. 


The information FloorQuery messages carry may depend on the user 
requesting the information. For example, a chair may be able to 
receive information about pending requests, while a regular user may 
not be authorized to do so. 
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13.5.1. Generation of the First FloorStatus Message 


The successful processing of a FloorQuery message by a floor control 
server involves generating one or several FloorStatus messages, the 
first of which SHOULD be generated as soon as possible. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the FloorQuery message into the FloorStatus 
message, as described in Section 8.2. 


If the FloorQuery message did not contain any FLOOR-ID attribute, the 
floor control server sends the FloorStatus message without adding any 
additional attribute and does not send any subsequent FloorStatus 
message to the floor participant. 


If the FloorQuery message contained one or more FLOOR-ID attributes, 
the floor control server chooses one from among them and adds this 
FLOOR-ID attribute to the FloorStatus message. The floor control 
server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 
each floor request associated to the floor. Each 
FLOOR-REQUEST-INFORMATION grouped attribute contains a number of 
attributes that provide information about the floor request. For 
each FLOOR-REQUEST-INFORMATION attribute, the floor control server 
follows the following steps. 


The floor control server MUST identify the floor request the 
FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor 
Request ID field of the FLOOR-REQUEST-INFORMATION attribute. 


The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
floors being requested (i.e., the floors associated with the floor 
request identified by the FLOOR-REQUEST-ID attribute). 


The floor control server SHOULD add a BENEFICIARY-ID attribute to the 
FLOOR-REQUEST-INFORMATION grouped attribute identifying the 
beneficiary of the floor request. Additionally, the floor control 
server MAY provide the display name and the URI of the beneficiary in 
this BENEFICIARY-INFORMATION attribute. 


The floor control server MAY provide information about the requester 


of the floor in a REQUESTED-BY-INFORMATION attribute inside the 
FLOOR-REQUEST-INFORMATION grouped attribute. 
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The floor control server MAY provide the reason why the floor 
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 


The floor control server MAY also add to the FLOOR-REQUEST- 
INFORMATION grouped attribute a PRIORITY attribute with the Priority 
value requested for the floor request. 


The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 
to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 
status of the floor request. The floor control server MAY add a 
STATUS-INFO attribute with extra information about the floor request. 


The floor control server MAY provide information about the status of 
the floor request as it relates to each of the floors being requested 
in the FLOOR-REQUEST-STATUS attributes. 


5.2. Generation of Subsequent FloorStatus Messages 


If the FloorQuery message carried more than one FLOOR-ID attribute, 
the floor control server SHOULD generate a FloorStatus message for 
each of them (except for the FLOOR-ID attribute chosen for the first 
FloorStatus message) as soon as possible. These FloorStatus messages 
are generated following the same rules as those for the first 
FloorStatus message (see Section 13.5.1), but their Transaction ID is 
0. 


After generating these messages, the floor control server sends 
FloorStatus messages, periodically keeping the client informed about 
all the floors for which the client requested information. The 
Transaction ID of these messages MUST be 0. 


The rate at which the floor control server sends FloorStatus 
messages is a matter of local policy. A floor control server may 
choose to send a new FloorStatus message every time a new floor 
request arrives, while another may choose to only send a new 
FloorStatus message when a new floor request is Granted. 


6. Reception of a ChairAction Message 


On reception of a ChairAction message, the floor control server 
follows the rules in Section 9 that relate to client authentication 
and authorization. If while processing the ChairAction message, the 
floor control server encounters an error, it SHOULD generate an Error 
response following the procedures described in Section 13.8. 


The successful processing of a ChairAction message by a floor control 
server involves generating a ChairActionAck message, which SHOULD be 
generated as soon as possible. 
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The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the ChairAction message into the 
ChairActionAck message, as described in Section 8.2. 


The floor control server needs to take into consideration the 
operation requested in the ChairAction message (e.g., granting a 
floor) but does not necessarily need to perform it as requested by 
the floor chair. The operation that the floor control server 
performs depends on the ChairAction message and on the internal state 
of the floor control server. 


For example, a floor chair may send a ChairAction message granting a 
floor that was requested as part of an atomic floor request operation 
that involved several floors. Even if the chair responsible for one 
of the floors instructs the floor control server to grant the floor, 
the floor control server will not grant it until the chairs 
responsible for the other floors agree to grant them as well. 


So, the floor control server is ultimately responsible for keeping a 
coherent floor state using instructions from floor chairs as input to 
this state. 


If the new Status in the ChairAction message is Accepted and all the 
bits of the Queue Position field are zero, the floor chair is 
requesting that the floor control server assign a queue position 
(e.g., the last in the queue) to the floor request based on the local 
policy of the floor control server. (Of course, such a request only 
applies if the floor control server implements a queue.) 


7. Reception of a Hello Message 


On reception of a Hello message, the floor control server follows the 
rules in Section 9 that relate to client authentication. If while 
processing the Hello message, the floor control server encounters an 
error, it SHOULD generate an Error response following the procedures 
described in Section 13.8. 


The successful processing of a Hello message by a floor control 
server involves generating a HelloAck message, which SHOULD be 
generated as soon as possible. The floor control server MUST copy 
the Conference ID, the Transaction ID, and the User ID from the Hello 
into the HelloAck, as described in Section 8.2. 


The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 
the HelloAck message listing all the primitives (i.e., BFCP messages) 
supported by the floor control server. 
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The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 
the HelloAck message listing all the attributes supported by the 
floor control server. 


8. Error Message Generation 


Error messages are always sent in response to a previous message from 
the client as part of a client-initiated transaction. The ABNF in 
Section 5.3.13 describes the attributes that an Error message can 
contain. In addition, the ABNF specifies normatively which of these 
attributes are mandatory and which ones are optional. 


The floor control server MUST copy the Conference ID, the Transaction 
ID, and the User ID from the message from the client into the Error 
message, as described in Section 8.2. 


The floor control server MUST add an ERROR-CODE attribute to the 
Error message. The ERROR-CODE attribute contains an Error Code from 
Table 5. Additionally, the floor control server may add an 
ERROR-INFO attribute with extra information about the error. 


Security Considerations 


BFCP uses TLS to provide mutual authentication between clients and 
servers. TLS also provides replay and integrity protection and 
confidentiality. It is RECOMMENDED that TLS with non-null encryption 
always be used. BFCP entities MAY use other security mechanisms as 
long as they provide similar security properties. 


The remainder of this section analyzes some of the threats against 
BFCP and how they are addressed. 


An attacker may attempt to impersonate a client (a floor participant 
or a floor chair) in order to generate forged floor requests or to 
grant or deny existing floor requests. Client impersonation is 
avoided by having servers only accept BFCP messages over 
authenticated TLS connections. The floor control server assumes that 
attackers cannot highjack the TLS connection and, therefore, that 
messages over the TLS connection come from the client that was 
initially authenticated. 


An attacker may attempt to impersonate a floor control server. A 
successful attacker would be able to make clients think that they 
hold a particular floor so that they would try to access a resource 
(e.g., sending media) without having legitimate rights to access it. 
Floor control server impersonation is avoided by having servers only 
accept BFCP messages over authenticated TLS connections. 
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Attackers may attempt to modify messages exchanged by a client anda 
floor control server. The integrity protection provided by TLS 
connections prevents this attack. 


An attacker may attempt to fetch a valid message sent by a client to 
a floor control server and replay it over a connection between the 
attacker and the floor control server. This attack is prevented by 
having floor control servers check that messages arriving over a 
given authenticated TLS connection use an authorized user ID (i.e., a 
user ID that the user that established the authenticated TLS 
connection is allowed to use). 


Attackers may attempt to pick messages from the network to get access 
to confidential information between the floor control server and a 
client (e.g., why a floor request was denied). TLS confidentiality 
prevents this attack. Therefore, it is RECOMMENDED that TLS be used 
with a non-null encryption algorithm. 


15. IANA Considerations 


The IANA has created a new registry for BFCP parameters called 


"Binary Floor Control Protocol (BFCP) Parameters". This new registry 
has a number of subregistries, which are described in the following 
sections. 


15.1. Attribute Subregistry 


This section establishes the Attribute subregistry under the BFCP 
Parameters registry. As per the terminology in RFC 2434 [4], the 
registration policy for BFCP attributes shall be "Specification 
Required". For the purposes of this subregistry, the BFCP attributes 
for which IANA registration is requested MUST be defined by a 
standards-track RFC. Such an RFC MUST specify the attribute’s type, 
name, format, and semantics. 


For each BFCP attribute, the IANA registers its type, its name, and 


the reference to the RFC where the attribute is defined. The 
following table contains the initial values of this subregistry. 
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Initial values of the BFCP Attribute subregistry 


15.2. Primitive Subregistry 


This section establishes the Primitive subregistry under the BFCP 


Parameters registry. 


As per the terminology in RFC 2434 [4], the 


registration policy for BFCP primitives shall be "Specification 


Required". 


For the purposes of this subregistry, the BFCP primitives 


for which IANA registration is requested MUST be defined by a 


standards-track RFC. 


name, format, 


For each BFCP primitive, 


an 


d semantics. 


Such an RFC MUST specify the primitive’s value, 


the IANA registers its value, its name, and 


the reference to the RFC where the primitive is defined. The 
following table contains the initial values of this subregistry. 
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Initial values of the BFCP primitive subregistry 


15.3. Request Status Subregistry 


This section establishes the Request Status subregistry under the 


BFCP Parameters registry. 


the registration policy for BFCP request status shall be 


"Specification Required". 


defined by a standards-track RFC. 


As per the terminology in RFC 2434 [4], 


For the purposes of this subregistry, the 
BFCP request status for which IANA registration is requested MUST be 


and the semantics of the request status. 


For each BFCP request status, 


meaning, 
defined. 


Such an RFC MUST specify the value 


the IANA registers its value, its 


and the reference to the RFC where the request status is 
The following table contains the initial values of this 
subregistry. 


Table 8: 


Camarillo, 


et al. 


+ ey e al pee 
| Value 
+ A A 
| 1 
| 2 
3 
| 4 
| 5 
| 6 
| 7 
+ Se rea al 


+----------- +------------ + 

| Status | Reference 

+----------- 4+------------ + 

| Pending | [RFC 4582] 

| Accepted [RFC 4582] 
Granted [RFC 4582] 

| Denied | [RFC 4582] 

| Cancelled | [RFC 4582] 

| Released | [RFC 4582] 

| Revoked | [RFC 4582] 

+----------- 4+------------ + 
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15.4. Error Code Subregistry 


This section establishes the Error Code subregistry under the BFCP 
Parameters registry. As per the terminology in RFC 2434 [4], the 
registration policy for BFCP error codes shall be "Specification 
Required". For the purposes of this subregistry, the BFCP error 
codes for which IANA registration is requested MUST be defined by a 
standards-track RFC. Such an RFC MUST specify the value and the 
semantics of the error code, and any Error Specific Details that 
apply to it. 


For each BFCP primitive, the IANA registers its value, its meaning, 
and the reference to the RFC where the primitive is defined. The 
following table contains the initial values of this subregistry. 


+------- AO = ---- -- 5-5 5 = +------------ + 
| Value | Meaning | Reference | 
+------- AO = ---- $= = +------------ + 
| a | Conference does not Exist | [RFC 4582] | 
| 2 | User does not Exist | [RFC 4582] | 
| 3 | Unknown Primitive | [RFC 4582] | 
| 4 | Unknown Mandatory Attribute [RFC 4582] 

5 Unauthorized Operation [RFC 4582] 
| 6 | Invalid Floor ID | [RFC 4582] | 
| af | Floor Request ID Does Not Exist | [RFC 4582] | 
| 8 | You have Already Reached the Maximum Number | [RFC 4582] | 
| | of Ongoing Floor Requests for this Floor | 
| 9 | Use TLS | [RFC 4582] | 
+------- AO = -- $= $$ = +----------- + 


Table 9: Initial Values of the Error Code subregistry 
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